Meeting Pearls 1/Meeting Pearls Vol 1 (1994).iso/installed_progs/text/faqs/386bsd-faq.part8

Internet Message Format | 1994-04-02 | 9.9 KB

Subject: [comp.os.386bsd] BNR/2 derived BSD for PCs FAQ (Part 8 of 10)
Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
From: [e-mail] (Dave Burgess)
Date: 31 Mar 1994 21:37:54 -0000

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part8

Section 7.    (System Communication and Network Information)

7.0    Communications

    386bsd and its kith support a wide range of communications methods.

7.1    SLIP

    Serial Line I/P is supported in all versions of Net/2 derived BSD.

    Brian <[e-mail]> provides us with a rather
    good explanation of some of the hurdles that must be overcome
    for a working slip interface.

    The idea is (overview) that you make a serial line connection to
    the host, set the line discipline, and tell your router to use
    this interface as your gateway.  You also should set the gateway
    up as a nameserver.

    Sounds easy ? - well it is if you've done it before.

    The _usual_ way of doing this is as follows:

    Both server and client must know eachothers inet addresses.  Set
    these up in /etc/hosts with lines saying
        11.22.33.44 host.my.domain.name host
        11.22.33.55 client.my.domain.name client

    where 11.22.33.?? is your inet number, and the following name is
    the full machine name (and is followed by any number of aliases).

    SERVER:
       Create a login - usually Sclientname - and run `sliplogin` as
       its shell.  I've looked at the docs for sliplogin, and it seems
       fairly straightforward.  [Ed.Note - I have; it is.]
       A fairly common problem on the server is an error that is
       caused by the lack of a 'sliplogin' entry in the /etc/shells
       file.  Be sure to add sliplogin to your shells file.

    CLIENT:
      Set up /etc/resolv.conf to say the following (for the nameserver)
        domain client.my.domain.name
        nameserver 11.22.33.55

      ** traditional method **
      - Log on to the server.  This is usually done via kermit or some
      such program.
      - Exit the program (or backround it if your line wants to drop
      once the device is closed).
      - Run `slattach /dev/comport` for whatever "comport" is.  On most
        Net/2 derived systems, this may be either com0, or cua01, or
        whatever the correct name is for your site.

      If you run into an error that says 'not configured' in it, your
      kernel either does not recognize your port (dmesg will verify that)
      or your kernel does not have the slip interface built in.  See
      below for the latter.  The former could be caused by any one of
      a dozen problems, including conflicting or incorrectly identified
      IRQs or port addresses.

      - Run `ifconfig inet sl0 clientname servername netmask 0xffffff00`
      - Run `route add default servername`.

        "servername" is your server and "clientname" is your client.

      It should now be possible to `ping host`

    ** my method **
      Configure /etc/remote
      Configure /etc/host.dial
      Run `slip host`.

    /etc/remote contains an extended `tip` entry.  /etc/host.dial
    contains a login script (and is named in /etc/remote).

    Oh yes, don't forget to have a line in your kernel config saying

    pseudo-device sl 2

    Without this line, you may get a 'device not configured' or
    'TIO...' error because the slip driver is not built into the
    kernel.

    I uploaded the slip package a while ago (to several archives), but
    was unaware of needing to notify the postmaster.  They've probably
    all been removed now.  Slip packages are available from many FTP
    sites; use archie to find the site nearest you.


7.2    CSLIP

    SLIP is included in the NetBSD-0.9 stock kernel and in the source
    tree.  It is also available in FreeBSD.


7.3    PPP

    Implementations of Point to Point Protocol are also available.  PPP
    should be available in the next major release (0.9+) of NetBSD and
    in the current release of FreeBSD.

    It should also be noted that there is a newsgroup that covers the
    PPP protocol exclusively.  It is comp.protocols.ppp.


7.4    TCP/IP

    TCP/IP is an integral part of Net/2 BSD.  There are at least five
    different network card drivers.  TCP/IP is fully supported and is
    available to all users of Net/2 derived BSD systems.  In fact,
    many people believe that this area is one of the primary advantages
    that Net/2 has over Linux.


7.5    UUCP

    There is an excellent document included in the UUCP directory
    that describes in detail, what needs to be done to get a working
    UUCP for Net/2 BSD systems.  Look in the /usr/src/gnu/libexec/uucp
    directory for more information.  You can also look in the
    /usr/share/doc/smm/09.uucpimpl and /usr/share/doc/smm/21.uucpnet
    if yours are populated.


7.5.1    TIP/CU

    First thing you need to do is...

        vi /etc/remote

    Then remove the two lines at the bottom of the file that mention
    com1, and com2.  Now add the following lines:

        com0:dv=/dev/com0:br#9600:
        com1:dv=/dev/com1:br#9600:

    That tells tip/cu where to find your com ports.  Next you need
    to be logged in as root and do a:

        chown uucp.dialer /dev/com0
        chown uucp.dialer /dev/com1
        touch /var/log/aculog
        chown uucp.dialer /var/log/aculog

    Make sure that, if you are running newsyslog, you change the
    owner.group entry in the newsyslog.conf file so that the file
    ownership is maintained correctly.

    Then you should be all set, remember "DOS Com1" = com0, and
    "DOS Com2" = com1.  So, if your modem is at 0x2F8/IRQ=3 and you
    access it as the COM2: port from DOS, you would do..

        tip com1

    To exit, type <RETURN>~.<RETURN>

    Many people have a problem with the lock open: procedure.
    If you receive the error:

    lock open: no such file or directory
    all ports busy

    You need to create a directory: /var/spool/lock, owned by uucp.  If
    this file already exists and is owned correctly, make sure that the
    lock file in the directory is deleted.

    This answer thanks to ([e-mail]).


7.5.2    What is the magic incantation that allows the modem to dial?

    Try 'stty -f /dev/tty0? clocal'.  Change the '?' for whatever
    character is appropriate for your tty port.  Remember, DOS COM1 =
    /dev/tty00 and DOS COM2 = /dev/tty01...

    Some other things that might cause some problems are the entries
    in the /etc/remotes file.  Try 'com?:dv=/dev/tty0?:br#19200:pa=none'
    and see if that helps.  Remember to replace the '?' with '[01234]'
    as appropriate.


7.6    Terminals

    Since the target machine for most Net/2 machines is a 386 with
    no more than a couple of serial ports, most people do not bother
    with serial terminals.  For most problems, a quick perusal of the
    man pages for the ttys file and getty are enough to get them
    started.  Other than that, most terminal problems are limited to
    peculiarities of particular terminals.

    One common problem that appears to crop up from time to time is
    which wires need to be connected at each end of the cable.  Most
    cables do not, in fact, pass through all lines.  If your terminal
    uses XON/XOFF (DC1/DC3) protocol, a cable of the appropriate
    twist, either straight through or null modem, can have as few as
    three lines connecting the two devices.  Assuming DB-25 connections
    at each end, the lines need to go from 2 to 3, 3 to 2, and 7 to 7.
    These lines are Rx, Tx, and gnd.  Other lines that may or may not
    be required include 4 and 5; and 6, 8, and 20.  Normally, these
    lines would be connected within the 'hood' of the cable (4 to 5
    and 6 and 8 to 20) to simulate the functionality of the full
    blown cable.  While full support for CTS/RTS is not available
    (yet), other support for the remainder of these lines is available
    or is being worked on in all Net/2 derived systems.  Without this
    handshaking (particularly pins 6, 8, and 20) your ports may appear
    to be dead.  This is because most of the tty driver for *BSD
    systems require a Data Carrier Detect to be active before the
    port will work.

    For those folks that have hardware flow control working, you need
    to look in the man page for 'stty' and look around for the
    -clocal and -ctrcrts options.

    Once the cable is set up, you will need to make sure that your
    system is ready.  The first thing you will need to do is make all
    of the devices in the /dev/ directory.  A program, called MAKEDEV,
    is available in the /dev directory.  Running this program with
    the argument 'tty' will make all of the physical tty devices.

    With that done, arranging for a 'getty' on the port is the next
    order of business.  You will need to edit the '/etc/ttys/' file
    and make one of the tty devices available.  If you have
    connected your terminal to DOS COM1, you will be enabling /dev/tty00.
    Similarly, if you are connected to COM2:, you will be enabling
    /dev/tty01 (see the pattern?).  There are other names for those
    ports as well, but when you are talking about terminals, be sure
    to use the /dev/tty* names.  If not, you will be completely
    ignored and treated as an outcast because you obviously have not
    done any of your homework.

    One of the other common problems with the SIO driver is that
    people will often disable all handshaking, and then complain that
    they cannot get a reliable connection above 9600 baud.  Handshaking
    is the solution to most of these problems.



7.7    Can network attached assets be used by/from NetBSD?

    Yes, they can, assuming the machine at the other end of the
    connections is reasonably cooperative.  The specifics are up to the
    remote machine, but a couple of things that you can start looking
    for that will help are provided below:

        -  Ask the system administrator of the machine in question
           if it is OK for you to use whatever it is you need.  This
           is more a matter of manners than a technical issue.

        -  For NFS mounted disk drives, make sure that you are not
           prevented from using the assets by the /etc/exports
           (or equivalent) file.  This goes for CD-ROMs as well as
           regular mounted disks.

        -  There are a completely different set of concerns for
           tapes and printers.  Each system implements these in
           slightly different ways.  Check with your system manager
           or documentation for more information.